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Verfahren zur automatischen Sof twaregenerierung 

Die Erfindung betrifft ein Verfahren zur automatischen 
Sof twaregenerierung, bei dem die Eigenschaf ten einer durch 
die Software ermoglichten Applikation (Anwendung) abstrakt 
modelliert und anschlieSend maschinell in Software fur die- 
se Applikation umgesetzt werden, wobei durch Ausfuhrung der 
Applikation ein gegebenenf alls aus mehreren Systemen zusam- 
mengesetztes technisches System beeinfluSt wird. 

Zur Erhohung der Effektivitat bei der Sof twareentwicklung 
werden in zunehmenden Mafie beschreibungsbasierte Verfahren 
eingesetzt. Hierbei werden unabhangig von klassischen Pro- 
grammiersprachen die Eigenschaf ten einer Anwendung abstrakt 
modelliert und spater maschinell in Software fur die Appli- 
kation umgesetzt. Vorteil dieser Verfahren ist eine signi- 
fikante Zeiteinsparung bei der Entwicklung aufgrund eines 
hoheren Abstrakt ionsgrades, sowie dem Ent fallen der manuel- 
len Trivialcodeerstellung. 

Fur die Applikat ionsmodellierung, d.h. zum Erstellen der 
Applikationsbeschreibung, sind beispielhaft folgende Metho- 
den bekannt : Obj ektorientierung (Vererben, Uberladen, Vir- 
tualisieren etc.); Hierarchisierung; Kapselung; Modulari- 
sierung; Instanzierung; Integration von konventionellen 
Programmiersprachen und mathematischen Modellen; Funktions- 
modellierung mit abstrakten Modellen; Generatoren fiir Be- 



nut zeroberf lachen und Datenstrukturen sowie deren Verarbei- 
tung . 

Nach der Modellierung erfolgt anhand der Applikationsbe- 
schreibung die automatische Generierung des Applikations- 
quellcodes. Vorher konnen im Rahmen einer Vorverarbeitung 
auf die Applikationsbeschreibung verschiedene Praprozesso- 
ren und Pruf programme angewendet werden, urn logische Feh- 
ler, Widerspruche, Zeigerf ehler , Codeleichen etc. zu erken- 
nen . 

In der Regel ist die Erzeugung des Applikationsquellcodes 
jedoch nicht ausreichend, Beispielsweise konnen Dokumenta- 
tionen ftir den Benutzer, aber auch flir den Programmier 
selbst benotigt werden. Wiinschenswert ist auch Software zur 
Visualisierung sowie Simulation der Applikation selbst so- 
wie des durch die Applikation beeinf luftten technischen 
Systems, d.h. Simulation der von der Applikation benotigten 
aulieren Parameter sowie der von der Applikation erzeugten 
Einfliisse auf das System. 

Nachteil der existierenden Generierungsverf ahren ist die 
Tatsache, daft die, zum Applikationsquellcode gehorende Zu- 
sat zinf ormationen und -software nicht oder nur bruchstuck- 
haft generiert werden, Folglich ist hier eine manuelle Er- 
stellung bzw. eine Nachbearbeitung oder eine separate Gene- 
rierung durch den parallelen Einsatz von unterschiedlichen 
Verfahren notwendig. Da in diesen Fallen mehr als nur eine 
Designquelle erforderlich ist, ergeben sich die folgenden 
entscheidenden Nachteile: 

ungeniigende Ausnutzung von Inf ormationen und moglichen 

Synergieef f ekten; 



r , redundante Inf.ormationen mit.. der Folge einer. hohen. 
Wahrscheinlichkeit von Inkonsistenzen; 

ein insgesamt erheblich erhohter Entwicklungs- und 
Pf legeauf wand . 

Aufgabe vorliegender Erfindung ist es daher, aus einer zen- 
tralen Designquelle fiir eine bestimmte Applikationssof tware 
eine redundanzf reie , effektive und vollstandige Generierung 
aller benotigten Inf ormationsziele zu ermoglichen. 

Diese Aufgabe wird erf indungsgemaiS durch ein Verfahren ge- 
maS Anspruch 1 gelost. Vorteilhafte Ausgestaltungen ergeben 
sich aus den Unteranspriichen sowie aus der nachf olgenden 
Beschreibung . 

Beim erf indungsgemafien Verfahren werden aus einer neuarti- 
gen model lier ten Applikationsbeschreibung neben dem Appli- 
kationsquellcode (oder der hierzu notwendigen Quellinf orma- 
tionen) iri einer vollstandig integrierten Form alle beno- 
tigten Inf ormationsziele generiert, wobei diese Inf ormati- 
onsziele zumindest eines der folgenden Zusatzelemente um- 
fassen: 

Software zur Visual isierung und/oder zur Protokollie- 
rung und/oder zur Fernuberwachung/-bedienung der Ap- 
plikation und/oder des technischen Systems; 
Software zur Simulation der Applikation und/oder des 
technischen Systems und eventuell zur Kontersimulation 
des technischen Systems, d.h. der auSeren Einflusse 
und Wechselwirkungen; 

Software und/oder benotigte Inf ormationen zur Kommuni- 
kation innerhalb der Applikation und/oder mit anderen 
Systemen und/oder zwischen verteilten Systemen, d.h. 



zwischen Systemen, die physikalisch getrennt , jedoch 
durch Datenaustausch verbunden sind; 

Dokumentationen fur den Anwender (Nutzer) der Applika- 
tion und/oder fur den Programmierer (Ersteller) der 
Applikation) . 

Ein wichtiger Aspekt ist, dass der erf indungsgemafi erzeugte 
Applikationsquellcode sowie die Zusat zelemente plattform- 
unabhangig auf verschiedenen Piatt formeii laufen kann. 

Fur eine vorteilhafte Losung ist die Einhaltung der folgen- 
den Randbedingungen erf orderlich : 

Model lierung der vollstandigen Software ohne Redundan- 

zen; 

Generierung der Inf ormationsziele (Senken) ohne Nach- 
bearbeitung; 

Generierung der Inf ormationsziele (Senken) unabhangig 
von Programmiersprachen, Betriebssystemen und Hard- 
ware ; 

Unterstvitzung von verteilten sowie heterogenen Syste- 
men; 

direkte Unterstiitzung von textuellen/graphischen 
Mensch-Maschinen- Schnittstellen/Int erf aces; 
durchgangig objektorientierter Ansatz, z.B. bei Be- 
zeichnungen, Einheiten, Werteumfang etc. von Daten; 
Einbeziehung weiterf lihrender Inf ormationen (z.B. Er- 
klarungen, Hilfetexte, Kommentare) in die Modellie- 
rung ; 

multilinguale Modellierung der Applikation; 

einfache und vollstandige Portierbarkeit/Wiederver- 

wendbarkeit von Sof twareteilen . 
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Das erf indungsgemaSe Generierungsverf ahren ..geht in folgen- 
den Schritten vor: 

1. Erstellen einer Applikationsbeschreibung durch Model- 
lierung, wobei hier der prinzipielle Aufbau (Struk- 
tur) , nicht jedoch die konkrete Auspragung (Syntax) 
relevant ist. Die Erstellung erfolgt vorteilhaf terwei- 
se mit einer entsprechenden Bearbeitungssof tware (Edi- 
tor) . 

2. Optionale tnaschinelle Vorverarbeitung der Applikati- 
onsbeschreibung, wie beispielsweise Praprozessierung 
und Optimierung, sowie die Anwendung von allgemein be- 
kannten Methoden zur Verbesserung/Sicherung der Soft- 
warequalitat . 

3. Mehrzielige vollintegrierte Generierung der Informati- 
onssenken (oben aufgefuhrte Zusatzelemente) . 

Im folgenden soil zunachst der Aufbau der Applikationsbe- 
schreibung dargestellt werden. 

Die Applikationsbeschreibung besteht beim erf indungsgemaSen 
Verfahren vorteilhaft aus hierarchisch geschachtelten Modu- 
len, Zusatzinf ormationen sowie Instanzierungstabellen, die 
den Applikationsteil eines Projektes vollstandig beinhal- 
ten. In vorteilhaf ter Ausgestaltung werden Module und deren 
Zusatzinf ormationen in sinnvoller Weise auf verschiedene 
Projekt- Oder Bibliotheksdateien verteilt. Ein Modul bzw. 
eine Projektdatei kapselt typischerweise ein Teilproblem 
der Anwendung . 

Ein Modul besteht konzeptionell aus mindestens folgenden 
Def initionsgruppen, die zur vollstandigen Festlegung minde- 
stens erforderlich sind, wobei in realer Anwendung diese 
aber auch nur teilweise auftreten konnen: 
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Knotendef initionen; 
Untermoduldef initionen; 
El ement de f ini t i onen ; 

Mensch-Maschine-Schnittstellendef initionen 
(MMI=Mensch-Maschine- Interface) ; 
Funktionsdef initionen . 

Jede Def initionsgruppe kann beliebig viele (Einzel-) Defi- 
nitionen beinhalten. Funktion und Bedeutung dieser Einzel - 
def initionen werden weiter unten beschrieben. 

Die 2ur Applikationsbeschreibung weiterhin vorteilhaft ver- 
wendeten Zusatzinf ormationen beinhalten Inf ormationen wie 
Texte, Bilder, Visualisierer , Typdef initionen etc., auf die 
innerhalb der Module Bezug genommen (ref erenziert ) wird. In 
vorteilhaf ter Ausgestaltung werden diese Zusatzinf ormatio- 
nen mit den zugehorigen Modulen in der selben Projektdatei 
abgelegt, die dann eine vollstandig autarke und wiederver- 
wendbare Einheit bildet . 

SchlieSlich konnen vorteilhaft Instanzierungstabellen zur 
Applikationsbeschreibung verwendet werden, die Informatio- 
nen beinhalten, die aufgrund von Mehrf achinstanzierungen 
der Module nicht im Modul direkt abgelegt werden konnen, 
und die sich ebenfalls nicht maschinell generieren lassen. 
Ein Beispi'el hierfiir sind Hardwareadressen . 

Im folgenden soli der Aufbau eines Moduls zur Applikations- 
beschreibung beim erf indungsgemaSen Sof tware-Generierungs- 
verf ahren erlautert werden . 

Da es fur eine konkrete Formulierung (Syntax) der obenge- 
nannten Def initionen beliebige Ausgestaltungen gibt, ist in 



der folgenden Beschreibung der Def initionsgruppen. nur prin- 
zipiell deren Aufbau sowie Inhalt dargestellt. Alle defi- 
nierten Bestandteile verfiigen jeweils iiber die fur die Sen- 
ken (Inf ormationsziele) erf orderlichen Attribute und Infor- 
mationen . 

Knotendef initionen : 

Diese Definition erlaubt die Verteilung der Applikation auf 
korperlich getrennte und datenteehnisch gekoppelte Hard- 
waresysteme (verteilte Systeme) . Durch Verwendung dieser 
Definition werden das zugehorige Modul sowie dessen eventu- 
elle Untermodule eine logisch eigenstandige Einheit. Vor- 
teilhaf terweise konnen hieraus mehrere Senken gleichen Typs 
(z.B. Applikationssof tware fiir die einzelnen Knoten von 
verteilten Hardwaresystemen) erzeugt werden. 

Beispielhaf te Attribute sind hier: Knotenname, Informa- 
tionstext. Art der Hardware (Leistungsfahigkeit) , Art der 
Kommunikation (Adresse) , 

Untermoduldef initionen : 

Diese Definition erlaubt die Instanzierung (Einbindung) von 
Unter modul en . 

Attribute sind hier beispielhaf t : Modulname, Inf ormat ions - 
text, zu libergebende Parameter. 

Elementdef initionen : 

Unter Elementen sind alle Daten sowie Hardwareein-/ausgange 
des Moduls zusammengef aSt . Diese werden mit einem Typ (z.B. 
numerisch, alphanumerisch, selektiv, Zeit, Datum, etc.) so- 
wie einer Zugehorigkeit/Verwendung (z.B. Parameter, Zu- 



. standsdaten, MeSdaten, Hardwareein-/ausgange, Zeitgeber, 
Zahler, Gleichungsdaten, etc.) attributisiert . 

Hardwareeingange konnen ferner liber Kontersimulationsglei- 
chungen verfiigen, die eine virtuelle Nachbildung der Um- 
weltreaktionen zum Zwecke einer moglichst realistischen Si- 
mulation darstellen. 

Elemente lassen sich zu Strukturen sowie n-dimensionalen 
Feldern zusammenf assen . Elemente sind obj ektorientiert an- 
gelegt, d.h. sie erlauben z.B. der.en Zugriff und Darstel- 
lung ohne Beachtung des Typs und der Zugehorigkeit/Ver- 
wendung . 

Attribute sind hier beispielhaf t : Elementname, Informa- 
tionstext, Datentyp, Zugehorigkeit (Verwendung) , Standard- 
wert , Wertebereich, Einheit , Darstellungs-/Editierberechti - 
gungen. Hardware zuordnung, Kontersimulationsgleichungen . 

Mensch-Maschinen-Schnittstellendef initionen : 

Diese umf assen alle einem Modul zugehorigen MMI (Mensch- 
Maschine-Interf ace) -Telle fur die Applikation sowie fur die 
erf indungsgemalS generierten Zusatzelemente (Inf ormations- 
ziele, Senken) . Vorteilhaf terweise wird die MMI -Definition 
nochmals in Untergruppen, sogenannten Oberflachen zerlegt, 
wobei eine Oberflache einen abgeschlossenen Tell des MMI 
beinhaltet (z.B. Parameterbearbei tung , Zustandsdarstellung , 
Prozessvisualisierung, etc.) . 

Die eigentliche MMI -Definition kann beispielhaf t mit fol- 
genden Befehlen erfolgen: 

Text, Bild, Linie, Rechteck, Kreis, Bitmap, Definition 

von Unterbildern; 



r- ^ Elemente darstellen (als Text oder in graphischer 
Form) , Histogramme darstellen; 

Seiten, Meniis, Listen, Schaltf lachen (Buttons) ; 
Aktionen (Manipulation von Elementen, Verzweigungen in 
den Menus, Seiten, Oberf lachen) ; 

bedingte Oberf lachenteile in Abhangigkeit von Elemen- 
ten . 

Ferner wird vorteilhaf terweise bei der Darstellung von Ele- 
menten automat i sch auf deren obj ektorientiert hinterlegte 
Attribute, wie Name, Beschreibung, Einheit und Darstel- 
lungsattribute, zuruckgegrif f en . 

Funktionsdef initionen; 

Die Funktionsdef inition eines Moduls besteht aus einer be- 
liebigen Anzahl von Funktionen. Die Art der Beschreibung 
kann - auch gemischt - in beliebiger Form erfolgen, z.B. 
durch konventionelle Programmiersprachen, abstrakte Model - 
le, etc., und wird gegebenenf alls von externen Compilern 
umgesetzt . 

Eine Funktion beinhaltet typischerweise eine logische Teil- 
funktion des Moduls und verfugt liber Attribute, mit denen 
das Betriebssystem des Zielsystems die Abarbeitung steuern 
kann (z.B. Permanentabarbeitung, zeitkritisch/-unkritisch, 
Auf rufhauf igkeit , ereignisgetriggert , MMI -getriggert ) . 

In vorteilhaf ter Ausgestaltung kann von der Funktionsdef i - 
nit ion auf die Elemente zugegriffen werden. 

Nach dieser Beschreibung des Modulaufbaus sollen im folgen- 
den die Eigenschaf ten einer vorteilhaf ten Applikationsbe- 
schreibung konzeptionell dargelegt werden : 
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Module konnen beliebig parallel und/oder hierarchisch 
angefordert warden sowie deren Eigenschaf ten an andere 
Module vererben. 

Die Instanzierung der Module erfolgt liber globale In- 
stanzierungslisten, oder wahlweise bei Einf achinstan- 
zierung auch direkt im Modul . 

Module konnen als autarke Einheit modelliert werden, 
d.h. sie beinhalten alle benotigten Inf ormationen lo- 
kal und konnen daher sehr einfach weiterverwen- 
det/iibertragen werden. 

Die Verwendung von Bibliotheken ist fur Module als 
auch fur Zusatzinf ormationen in jeder genannten Infor- 
mationsart moglich (Texte, Bilder, Visualisierer , . Da- 
tentypen, Funktionen etc.) 

Element- und Modulattribute werden obj ektorientiert 
(Virtualitat ) behandelt , 

Alle Bestandteile einer Applikationsbeschreibung wer- 
den mit weiterfuhrenden Inf ormationen attributisiert , 
wobei diese Inf ormationen an alle Senken weitergegeben 
werden . 

Die Ablage der Inf ormationen eines/mehrerer Module er- 
folgt in einer Datei . Untermodule (sofern diese wei- 
terverwendet werden sollen) und Bibliotheken werden in 
separaten Dateien abgelegt. 

Die Losung von komplexen Applikationen mit verteilter 
und ggf . heterogener Hardware bzw. mit Multiprozessor- 
systemen erfolgt vorteilhaft in einer zentralen Be- 
schreibung, in der die Verteilung der Module statisch 
Oder dynamisch beschrieben wird. 



Nachdem eine Applikationsbeschreibung nach den obengenann- 
ten Modellstrukturen vorgenommen worden ist, kann eine ma- 
schinelle Vorverarbeitung der Applikationsbeschreibung er- 



folgen, durch. die eine Optimierung, Qualitatssicherung. sb- 
wie eine Analyse und Uberpriifung nach Fehlern und Wider- 
spriichen erf olgt . Diese Voirverarbeitung ist in hohem Mafie 
abhangig von der verwendeten allgemeinen Syntax sowie von 
den verwendeten Beschreibungsf ormen innerhalb der Funktio- 
nen. Da beide beliebig ausgestaltet werden konnen, ist die 
sof twaretechnische Umsetzung der Verve rarbe it ung hier nicht 
relevant . 

Erf indungsgemaS konnen nunmehr mittels eines Zielgenerators 
maschinell /automat isch die verschiedenen Inf ormationsziele 
(Senken, Zusatzelemente zur eigentlichen Applikationsquel- 
linf ormation) ausgebildet werden. 

Da die genaue Ausbildung der Senken von Zielsystem, Pro- 
grammiersprache , Compiler, PC-Plattform etc. abhangt, wer- 
den fur die Senken lediglich deren erf indungsgemaSe Eigen- 
schaften beschrieben. Global gilt fiir alle Senken erfin- 
dungsgemaS, dafi diese wie im folgenden dargelegt direkt ge- 
neriert werden und/oder die Inf ormationen generiert werden 
(Quellcode und/oder Tabellen/Listen und/oder Binardaten 
und/oder andere Formen von Sof twareinf ormationen) , die eine 
Erzeugiing durch weiterf uhrende, externe Systeme ermogli- 
chen. Generierungsergebnisse konnen sein: 

Applikationsinf ormationen 

Strukturen zur (obj ektorientierten) Verwaltung der Mo- 
dule 

Strukturen zur (obj ektorientierten) Verwaltung der 
Elemente 

Appl ikat ions f unkt ionen 

Applikations-MMI (falls in Appl ikat ion vorhanden) 



Texte/Graf iken: in. multilingualer Form (falls in Appli- 
kation vorhanden) 

Bei verteilten Systemen kann fur die einzelnen Hardwa- 
reknoten eine entsprechend individualisierte Informa- 
tion generiert werden. 

Die generierte Information ist unabhangig von Compi- 
ler, Betriebssystem und Zielhardware . 

PC / Web -Visualisie rung 

Strukturen zur (obj ektorientierten) Kommunikation mit 
der Applikationshardware 

Strukturen zur (obj ektorientierten) Verwaltung der 
Elemente 

Visual isierungs-MMI 

Texte/Graf iken in multilingualer Form 

PC-Offline -Simulation 

Applikationsdef inition (s.o.) 

PC/Web-Visualisierung (s.o., zzgl. der Elemente zur 
Durchfuhrung der Konterisimulation) 

Anwende rdokumen t a t ion 

Liste Parameter (einschliefilich Attribute) 
Liste der Zustands-/MeSdaten 
Liste der Ein-/Ausgange 

Inf ormationen iiber die Funktionen der Applikation 
(falls in Applikationsbeschreibung vorhanden) 
Ubersicht der MMI-Struktur (falls in Applikation vor- 
handen) 

Detaildarstellung der einzelnen Telle des MMI sowie 
Informationen uber deren Bedienung und Funktionen 
(falls in Applikation vorhanden) 
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Sof twaredokumentation 

Anwenderdokumentation (s.o. ) 
Modulstruktur (Zusammenhange) 

Inf ormationen zur Strukturierung der Module unterein- 
ander 

Inf ormationen zum Moduleinhalt (einschlieSlich Funk- 
tionalitat ) 

Gegeniiber existierenden Sof tware-Generierungsverf ahren bie- 
tet das erf indungsgemaSe Verf ahren die folgenden Vorteile: 

Es existiert nur eine, redundanzf reie Softwarebe- 

schreibung; 

Alle Inf ormationsziele/Senken sind vollstandig gene- 
rierbar ; 

Inkonsistenzen sind innerhalb einer Senke sowie zwi- 
schen den einzelnen Senken unmoglich; 

Es ist keine manuelle Nachbearbeitung der einzelnen 
Senken erf order lich; 

Vollstandige integrierte Unterstutzung des Mensch- 
Maschine - Interface ; 

Hochgradige Ausnutzung der objektorientierten Model - 
lierung von Modulen und Elementen, insbesondere im 
Rahmen des Mensch-Maschine-Interf ace . 

In Summe ergibt sich eine erhebliche Verkiirzung des Ent- 
wicklungs-, des Dokumentations- und Pf legeauf wandes bei der 
Generierung von Software . 

Im folgenden sollen Ausf iihrungsbeispiele anhand der beige- 
fiigten Zeichnungen die Erfindung und deren Vorteile naher 
erlautern. 
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■Figur 1 zeigt eine ■ stark vereinfachte Darstellung einer 
moglichen Ausgestaltung des erf indungsgemaSen De- 
signf lusses zur Sof twaregenerierung . 

Figur 2 zeigt exemplarisch die Applikationshierarchisie- 
rung, d.h. die beispielhaf te Struktur einer Appli- 
kationsbeschreibung, die aus einer zentralen Pro- 
jektdatei sowie einer eingebundenen Projektdatei 
besteht . 



Figur 3 zeigt eine beispielhaf te - Bildschirmausgabe, die 
mit der erf indungsgemafi erzeugten Software zur Vi- 
sualisierung oder Simulation hergestellt werden 
kann . 

Figur 4 zeigt das Beispiel einer am Bildschirm ausgegebe- 
nen mit dem erf indungsgemaSen . Verfahren erzeugten 
Sof twaredokumentation . 



Die Figuren 1 und 2 erklaren schematisch und exemplarisch 
DesignfluS und Applikationshierarchisierung bei der erf in- 
dungsgemaSen Sof twaregenerierung . 

Im folgenden soil ein Applikationsbeispiel im Detail eror- 
tert werden. 



Problemstellung : 

Automatische Hartepriifung eines Werkstuckes durch Eindrin- 
gen einer konischen Stahlspitze in den Prufling mit folgen- 
dem Ablauf : 

1 . Auf bringen der Priif kraf t 
2 . Priif zeit abwarten 



3. Einlesen des MeSergebnisses 

4. falls Priifung i.O. => weiterleiten des Pruf lings 

falls Prufung nicht i.O. => Priifling als AusschuS aus- 
sortieren 

5. mit 1 fortfahren 

Beziiglich des Automat isierungssystems bestehen folgende 
Forderungen : 

Das Aufbringen der Priifkraft erfolgt durch Freigabe ei- 
nes Zylinders sowie Regelung der Priifkraft liber die 
Vorgabe Zylinderdruck (interne Regelung) . 

Das korrekte Aufbringen der Priifkraft wird von der 
Prufmaschine mit einer digitale Riickmeldung (Sensor) 
angezeigt. Bei fehlendem Signal (nach einer bestimmten 
Zeit) wird in einen Fehlerzustand verzweigt. 
Die eigentliche Hartepriifung erfolgt mit einem separa- 
ten Weg-MeSgerat , das dem Automatisierungssystem die 
Eindringtief e in Form eines analogen Signals libergibt . 
Die Applikation vergleicht dieses mit einem Sollwert 
und entscheidet uber i.O, / nicht i.O. (= n.i.O.). 
Das Prufergebnis wird einer externen Einheit in Form 
eines i.O. bzw. n.i.O. Ausganges zuganglich gemacht . 
liber ein gerateinternes MMI sollen die Parameter veran- 
derbar sein sowie der aktuelle Anlagenzustand darge- 
stellt werden. 

Uber eine serielle Schnittstelle soli eine externe Vi- 
sualisierungseinheit angeschlossen werden, die alle In- 
formationen des gerateinternen MMI sowie den Kraft - 
/Wegverlauf einer Prufung darstellt, Diese Software, 
sowie eine Software zur Offline-Simulation wird paral- 
lel aus gleicher Quelle generiert , 

Das Automatisierungssystem verfugt uber: 



Hardware -Eln-Ausgange : 

- Startsignal (zum Starten einer Priifung) (digitaler Aus- 
gang) 

- Endlagenriickmeldung der Priif kraf tauf bringung (digitaler 
Eingang) 

- Aktivierung der Priif kraf tauf bringung (digitaler Ausgang) 

- lO-Meldung (digitaler Ausgaing) 

- NIO-Meldung (digitaler Ausgang) 

- Vorgabe Zylinderdruck (analoger Ausgang) 

- Mefieingang: Prufkraft (analoger Eingang) 

- MeSeingang: Eindringtief e (analoger Eingang) 

Parameter: 

- Zeitlimit "Vorfahren" (der Kraf tauf bringung, bis Sensor 
erreicht ) ( in Sekunden) 

- Priifzeit (in l/lOs) 

- Prufkraft (Vorgabewert in l/lOkN) 

- max. Eindringtief e (in ^m) 

- min. Eindringtief e (in fim) 

- P-Anteil des Kraft PI-Reglers 

- I -Anteil des Kraft PI-Reglers 

ApplikationsbeschreibunqZ-modellieruna : 

GemaS dem beschriebenen Problem wird eine Losung model - 
liert, die aus den Modulen ModPriif (grundsatzliche Steue- 
rung des Priif ablaufs) und ModRegPI (PI-Regler) sowie Zusat- 
zinf ormationen besteht . 

Das Modul ModRegPI hat Bibliothekscharakter und kann ggf . 
schon in einer Bibliothek vorhanden oder in einer solchen 
angelegt werden . 



Iri; realer Ausf.uhrung kann das Modul ModPriif wiederum in 
groSeren Prozessen als Untermodul eingesetzt warden. 



Zusat zinf ormationen : 



Folgende Zusatzinf ormationen werden eingerichtet : 

Texte: multilinguale Texttabelle, die alle verwendeten 
Texte enthalt 

Bilder: Definition aller in den Modulen benotigten Bil- 
der/Graf iken 

Datentypen: 

TAusEin: selektiv, mogliche Zustande : AUS und EIN 
TKraft: numerisch, in [kN] , 1 Dezimalstelle , Bereich: 0.0 
. . .99.9 

TTiefei numerisch, in [jim] , ohne Dezimalstelle , Bereich: 
0 ... 2000 

TDruck: numerisch, in [bar] , 1 Dezimalstelle, Bereich: 
0.0 ... 15.0 

TSek: numerisch, in [s] , 1 Dezimalstelle , Bereich: 0.0 

... 60.0 

TProz: numerisch, in [%] , ohne Dezimalstelle , Bereich: 0 
. . .200 

Visualisierer : 

Defintionen, auf welche Art und Weise Daten/Inf ormationen 
im MMI dargestellt werden. 



Modul "ModPruf " : 
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Untermodule: • > 

- Eine Instanz von Modul ModReg. Instanzname : MRBgler 
Elemente : 

Start: Triggereingang zum Starten einer Priifung 

Datentyp: TAusEin, Zuordnung : dig. Eingang 

EndlagG: Riickmeldung Endlage erreicht 

Datentyp: TAusEin, Zuordnung: dig. Eingang 

Zylinder: Freigabe des Priif kraf t zylinders 

Datentyp: TAusEin, Zuordnung: dig. Ausgang 

lO'Meldung: lO-Meldung an eine externe Einheit 

Datentyp: TAusEin, Zuordnung: dig. Ausgang 

NIO-Meldungi NIO- Mel dung an eine externe Einheit 

Datentyp: TAusEin, Zuordnung: dig. Ausgang 

Eindringtiefe: MeSergebnis nach der Prufung 

Datentyp: TTiefe, Zuordnung: analoger Eingang 
Priifkraft: MeSwert der Prufkraft (aktueller Wert) 

Datentyp: TKraft, Zuordnung: analoger Eingang 

min, Eindringtiefe: unterer Grenzwert fur Eindringung 
Datentyp: TTiefe, Zuordnung: Parameter 

max. Eindringtiefe: oberer Grenzwert fur Eindringung 
Datentyp: TTiefe, Zuordnung: Parameter 

Priif dauer: Dauer der Eindringung 

Datentyp: TSek, Zuordnung: Parameter 

MMI-Steuer\ingssystein (zweizeiliges Display) : 

♦ falls aktueller Zustand ungleich BEREIT (= d.h. es 
wird gepriift) 

obere Zeile: aktuelle Eindringtiefe 



untere Zeile: lO/NIO-Meldung v;.- , • . \ 

♦ sonst (= d.h, es wird nicht gepriift) 
Kopfzeile mit Hautpmenumeldung 

untere Zeile: Darstellung eine Zeile des Hauptmeniis. 
Hier konnen die Parameter eingesehen und. verandert 
we r den. 

MMI-Visualisierxingssystem (PC unter Windows) : 

♦ Darstellung der Mefidaten sowie der Priif parameter in 
grafischer Form, ggf . auf mehrere Fenster verteilt 

Funktionen: (hier als Statusmaschine realisiert) 

Status BEREIT: Bei Eintreten: Die Ausgange Zylinder, 

lO-Meldung und NIO-Meldung inaktivie- 

ren aktivieren. 

Falls Eingang Start aktiv, dann zum 
Status ZYLINDER EIN 

Status ZYLINDER_EIN: Bei Eintreten: Den Ausgang Zylinder 

aktivieren, Zeit starten 
Falls Eingang Endlage aktiv, dann zum 
Status MESSEN 

Falls Zeit > 3s, dann zum Status 
ZYLINDER EIN 

Status MESSEN Bei Eintreten: von Untermodul MRegler 

das Flag Freigabe aktivieren, Zeit 
starten 

Falls (Zeit > PriifdauGr) UND {Ein- 
dringtiefe < min. Eindringtiefe) , 
dann zum Status TEST NIO 



■ r.- - Falls (Zeit > 'PrufdaUBir) ■ UND" {Ein- 

dringtiefe > max. Eindringtiefe) , 
dann zum Status TEST^NIO 
sonst, falls (Zeit > Prufdauer) zum 
Status TEST_IO 

Status TEST_IO Bei Eintreten: von Untermodul MRBgler 

das Flag Freigahe inaktivieren, Aus- 
gang lO-Meldung aktivieren, Ausgang 
Zylinder inaktivieren, Zeit starten 
Falls Zeit > 3s, dann zum Status 
BEREIT 



Status TEST_NIO Bei Eintreten: von Untermodul MRegler 

das Flag Freigahe inaktivieren, Aus- 
gang NIO-Meldung aktivieren, Ausgang 
Zylinder inaktivieren, Zeit starten 
Falls Zeit > 3s, dann zum Status 
BEREIT 

Status FEHLER nicht weiter spezifiziert 



Modul "ModRegPI " : 

Untermodule : 

keine 



Elemente : 

FreigaJbe: Triggereingang zum Starten einer Prufung 

Datentyp: TAusEin, Zuordnung : dig. Eingang 
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Prufkraft: Meliwert der Prufkraft (aktueller Wert) 

Datentyp: TKraft, Zuordnung: analoger Eingang 

Prufdruck: Meliwert der Prufkraft (aktueller Wert) 

Datentyp: TDruck, Zuordnung: analoger Ausgang 

P-Anteil : P-Anteil der Kraf tregelung (uber Druckausgang) 
Datentyp : TProz, Zuordnung : Parameter 

J-Anteil : I -Anteil der Kraf tregelung (iiber Druckausgang) 
Datentyp : TProz, Zuordnung : Parameter 

MMI - S t euerungs sy s t em : 

- nicht we iter spezif iziert - 

MMI- Visual isierungssys tern: 

- nicht weiter spezifiziert - 

Fxmkt ionen : ( z . B . al s Echt ze i t - C - Code ) 
Regelalgorithmus , nicht weiter spezifiziert 

Generierungsergebnisse : 
Applikationscode : 

Der in diesem Applikatioinsbeispiel erzeugte Quellcode be- 
inhalltet folgende Telle: 

Listen der Elemente, in denen alle erf orderlichen In- 
formationen und Attribute hinterlegt sind 
Klassen/Strukturen fur die angelegten Module 
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l>-^r' - Strukturen^/Instanzen zur Datenbeschreibung 

Strukturen-/Instanzen zur MMI -Beschreibung, die von 
einem Interpreter auf der Zielhardware abgearbeitet 
werden 

Verschiedene Funktionscodeteile die teilweise aus ei- 
ner Statusmaschinen generiert wurden 

Visualisierung : 

Diese ist dargestellt in Figur 3 (jedoch an einem anderen 
Beispiel) . 

Offline-Simulation : 

Die Offline-Simulation besteht prinzipiell aus der Visuali- 
sierung (vgl . Figur 3) sowie dem, fiir einen PC compilierten 
Applikationscode . Beide Telle werden intern gekoppelt, wo- 
bei sich durch die Koritersimulation eine nahezu realisti- 
sches Verhaltensweise ergibt . Optisch entspricht die Simu- 
lation weitgehend der Visualisierung. 

Dqkumentat ion : 

Diese ist dargestellt in Figur 4 (jedoch an einem anderen 
Beispiel) . 



:Herr Andreas Foitinek. 
70806 Kornwes t he im 
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20.11.2000/cb/mg 



Patentanspruche 

1. Verfahren zur automatischen Sof twaregenerierung, bei 
dem die Eigenschaf ten einer durch die Software ermoglichten 
Applikation (Anwendung) abstrakt modelliert und anschlie- 
Send maschinell in Software fiir diese Applikation umgesetzt 
werden, wobei durch Ausfuhrung der Applikation ein gegebe- 
nenfalls aus mehreren Systemen zusammengeset ztes techni- 
sches System beeinfluSt wird, 

dadurch gekennzeichnet, 

daS aus der modellierten Applikationsbeschreibung neben dem 
Applikationsquellcode oder neben der zur Erzeugung dieses 
Quellcodes geeigneten Quellinf ormation mehrzielig zumindest 
eines der folgenden Zusat zelemente in vollstandig inte- 
grierter Form generiert wird, namlich 

Software zur Visual isierung und/oder zur Protokollie- 
rung und/oder Fernuberwachung/-bedienung der Applika- 
tion und/oder des technischen Systems, 

Software zur Simulation der Applikation und/oder des 
technischen Systems, 

Software und/oder Inf ormationen zur Kommunikation in- 
nerhalb der Applikation und/oder mit anderen Systemen 
und/oder zwischen verteilten Systemen und 
Dokumentation fur den Anwender und/oder fiir den Pro- 
grammierer . 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet , dafi 
neben der Software zur Simulation der Applikation auch 



Software zur Kontersimulation des .technisGhen .Systems gene - 
riert wird, das durch die Applikation beeinfluSt werden 
soil . 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeich- 
net , daS die Applikation durch ein/eine oder mehrere Modu- 
le, Zusatzinf ormationen und evtl. Instanzierungstabellen. 
modelliert wird, wobei 

ein Modul vorteilhaf t - ein Teilproblem der Applikation 
beinhaltet , 

die Zusatzinf ormationen Inf ormationen wie Texte, Bil- 
der, Visualisierer und Typdef initionen enthalten, auf 
die innerhalb der Module Bezug genommen wird, und 
die Instanzierungstabellen Inf ormationen enthalten, 
die im Falle von Mehrf achinstanzierungen der Module 
nicht im Modul selbst abgelegt werden konnen und sich 
nicht maschinell generieren lassen, wie beispielsweise 
Hardware zuordnungen . 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet , daS 
ein Modul durch die folgenden Def initionsgruppen vollstan- 
dig festgelegt wird: 

Knotendef initionen zur Verteilung der Applikation auf 
physikalisch getrennte und datentechnisch gekoppelte 
Systeme (verteilte Systeme) , 

Untermoduldef initionen zur Instanzierung (Einbindung) 
von Untermodulen, 

Elementdef initionen zur Zusammenf assung aller Daten 
sowie Hardware- und Kommunikationsein-/ausgange eines 
Modul s , 

Mens ch-Maschine-Schnittstellendef initionen zur Defini- 
tion aller innerhalb eines Moduls benotigten Bestand- 



telle zum Heirsteilen einer Schnittstelle zum Benutzer 
und 

Funktionsdef initionen bestehend aus einer Anzahl von 
Funktionen eines Moduls. 



Herr Andreas Foltinek 
708 0 6 Kornwestheim 
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Z u s amme n £ a s s Xing 

Die Erfindung betrifft ein Verfahren zur automatischen 
Sof twaregenerierung, bei dem die Eigenschaf ten einer durch 
die Software ermoglichten Applikation (Anwendung) abstrakt 
modelliert und anschliefiend maschiniell in Software fur die- 
se Applikation umgesetzt werden, wobei durch Ausfiihrung der 
Applikation ein gegebenenf alls aus mehreren Systemen zusam- 
mengesetztes technisches System beeinfluEt wird. Es wird 
vorgeschlagen, dalS aus der modellierten Applikationsbe- 
schreibung neben dem Applikationsquellcode oder neben der 
zur Erzeugung dieses Quellcodes geeigneten Quellinf ormation 
mehrzielig zumindest eines der folgenden Zusatzelemente in 
vollstandig integrierter Form generiert wird, namlich 

Software zur Visualisierung und/oder zur Protokollie- 
rung und/oder Fernuberwachung/-bedienung der Applika- 
tion und/oder des technischen Systems, 

Software zur Simulation der Applikation und/oder des 
technischen Systems , 

Software und/oder Inf ormationen zur Kommunikation in- 
nerhalb der Applikation und/oder mit anderen Systemen 
und/oder zwischen verteilten Systemen und 
Dokumentation fur den Anwender und/oder fiir den Pro- 
grammierer. 
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